…, cooling, expiry guard

Closes the load-bearing gap from #43: the retry button was generating a
fresh idempotency_key on every click, defeating the partial unique index
that landed in PR #59. A doubled click or a click that races a webhook
could produce two intents → two charges. Same-key reuse turns those
races into ON CONFLICT no-ops.

retryFailedPayment() now:
- reuses parent.idempotency_key (FR-006); if absent (legacy intent), gens
  a fresh one and the retry chain still self-dedupes
- bumps retry_count on the new (child) row; throws PaymentRetryLimitError
  past RETRY_LIMIT=3 (FR-009)
- enforces COOLING_PERIOD_MS=30s since parent.created_at; throws
  PaymentRetryCoolingError carrying waitMs so UI can render countdown
  (FR-010)
- guards parent.expires_at; throws PaymentRetryExpiredError if the parent's
  24h provider session has lapsed
- upserts with onConflict:'idempotency_key', ignoreDuplicates:true — a
  doubled click returns null which we surface as \"original is the truth\"
  by returning the parent intent (no double-charge, no UI surprise)
- audit-logs every attempt as 'payment_retry' (NFR-007), including the
  deduped flag so admin analytics can distinguish a fresh retry attempt
  from a server-side dedupe of an already-won race

New libs:
- src/lib/payments/error-categorization.ts — pure mapping from Stripe +
  PayPal error_code (already in payment_results) to one of FR-002's 8
  categories with non-technical user message + resolution hint + a
  recoverable flag that gates the retry button (FR-001/003/006/NFR-001).
  27 tests including 'never leak raw provider text' and 'no technical
  jargon'
- src/lib/payments/audit.ts — logPaymentRetryEvent wrapper around
  logAuthEvent. Non-throwing; an audit-write failure must never break
  payment UX

Tests: 16 new in retry.test.ts (key reuse, cap, cooling, expiry,
dedupe-conflict path, audit emission), 27 in error-categorization.test.ts.
All 92 payment-service-area tests green; full suite 3249/3249.

Why on its own: this is the load-bearing change. UI commit follows and
just consumes the public surface (RETRY_LIMIT, error classes, hook).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ter, cooling button, offline banner

Consumes the service surface from the previous commit to surface the
retry UX gaps that #43 actually closes.

PaymentStatusDisplay (failed-state block rewritten):
- Renders categorized userMessage + resolutionHint instead of raw status
  (FR-001/003). Transaction reference shown for support inquiries (FR-004).
- Recoverable errors show retry button + 'Attempt N of M' counter (FR-008).
  Non-recoverable errors hide retry and show a Contact Support link
  (FR-019 lite — no wizard yet, US4 is a follow-up).
- Cooling state disables the button and shows 'Try again in 23s' that
  ticks down (FR-010). PaymentRetryLimitError / PaymentRetryCoolingError /
  PaymentRetryExpiredError thrown by the service surface client-side as
  retry-error alerts.

usePaymentRetryStatus hook:
- Reads parent intent, computes { retryCount, canRetry, disabledReason,
  coolingMsRemaining }. 1Hz tick while cooling so the countdown is live.
- A UX hint, not a security boundary — server-side checks in
  retryFailedPayment are still the source of truth. The hook just stops
  the user clicking a button that's certain to fail.
- 7 tests using vi.useFakeTimers({ shouldAdvanceTime: true }) so waitFor
  internals work alongside the controlled cooling tick.

OfflineRetryBanner (new 5-file component, peer of PaymentStatusDisplay):
- Reads useOfflineStatus + paymentQueue.getCount(). Renders a warning
  alert when offline (with queued count if any) and an info alert when
  online but queue still draining. Silent in the steady state.
- Mounted above PaymentStatusDisplay on /payment-result for the loaded
  state and above the not-found alert for the still-processing state.
- 7 unit + 1 a11y test, including singular/plural copy and a getCount
  rejection survives without throwing.

E2E (tests/e2e/payment/03-failed-payment-retry.spec.ts):
- Un-skipped 'should display offline error banner when offline' (was
  skipped pending offline UI). Uses context.setOffline(true) to force
  the navigator.onLine bit before navigation, asserts the banner copy.
  Closes one row of #53's skip index.

Verification:
- pnpm test: 3249/3249 across 286 files
- pnpm test:rls: 55/55 (new columns inherit existing policies as expected)
- pnpm run type-check: clean
- pnpm run lint: clean

Out of scope (deferred to a follow-up PR):
- User Story 3 (update payment method, FR-011-FR-015) — stripe.js + PCI
- User Story 4 (guided recovery wizard, FR-016-FR-019) — largest piece

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The test as shipped called context.setOffline(true) BEFORE page.goto(),
which works on a dev server (page is in cache after first hit) but fails
in CI's static-export flow with net::ERR_INTERNET_DISCONNECTED — there's
no service-worker cache warmed for this URL when the page first loads.

Fix: navigate online first, wait for the page to render the loaded /
not-found branch (both of which mount OfflineRetryBanner), then flip
offline. useOfflineStatus listens for the browser 'offline' event so the
banner re-renders without another navigation.

Same story as the diagnostic-loud failure modes PR #58 was designed to
catch — the failure was clear from the CI log so this is a one-shot fix.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…wser (#63)

Previous fix navigated online first, then called context.setOffline(true).
That works in Chromium (chromium-gen 3/6 went green) but fails in Firefox
and WebKit because Playwright's setOffline blocks request traffic without
firing the 'offline' browser event in those engines. useOfflineStatus only
listens for window 'offline' events, so the banner never re-renders.

Real browsers DO fire the event on real network drops, so synthesizing it
in the test is closer to production behavior than relying on Playwright's
imperfect cross-browser setOffline. Override navigator.onLine + dispatch
both 'offline' and (in cleanup) 'online' so subsequent tests don't see
stuck state.

Single-shard verification was the chromium-gen 3/6 success in the prior
attempt (run 25030125601); this commit extends the same path to
firefox/webkit.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>